BBS in a Box 4/BBS in a Box - Macintosh - Volume IV (January 1992) (BBS in a Box).iso/Files/Word/A-Ad/actor

Text File | 1987-05-25 | 15.6 KB | 336 lines | [TEXT/MACA]

EDITED TRANSCRIPT  11/16/86
Conference in the AI Forum on CompuServe with language designer Charles Duff.
Mr. Duff discusses Object-Oriented Programming, his language ACTOR, Smalltalk,
his language NEON, and more.
ACTOR for the IBM PC AT\AT is supported by Mr. Duff on the AI Forum.
For information on the $495 product, academic discounts, etc.:
  Charles B. Duff
  The Whitewater Group
  Technology Innovation Center
  906 University Place
  Evanston, IL 60201
  312 - 491 -2370

Conference participants are:
Charles Duff 70004,22
Susan Shepard, Primary Sysop, AI Forum  76703,4326
Jeff Gordon, Assistant Sysop  75465,722
Marc Rettig, Technical Editor, AI EXPERT, 76703,1037
John Anderson, Texas Instruments, 76266,1612


(Duff)  ACTOR is an OOL for the IBM XT/AT that runs under Microsoft Windows.
 It is presently a single-inheritance, fully object-oriented model.  Syntax is
 algorithmic, Pascal-like.  ACTOR uses a threaded interpreter, is very
 efficient, and is usable on current hardware.  We're targeting it as sort of
 the Rolls-Royce of Windows development systems, of which there are currently
 2.

(Shepard) What are the two?

(Duff) Us and Microsoft C.  ACTOR is the only interactive language under
 Windows.  Surprisingly, our performance in demos has proven quite comparable
 to C.

(Shepard) Could you talk a bit about the design details of Smalltalk and what
 you have done to improve upon them and then get into real-time garbage
 collection?

(Duff) Well, to begin, let me say that I'm inevitably cast into this role of
 throwing tomatoes at Smalltalk.  I really *like* Smalltalk and I'm very
 grateful for Alan Kay and PARC, etc.  ST has had a couple of problems, in my
 opinion.  One of course is performance.  Digitalk's very fine implementation
 is the first that is even useful on micros.  Much of the bottleneck is due to
 carrying the late-binding metaphor to the depths of the language.  We have
 addressed this by providing optional early binding in a simple, transparent
 way. Next, Smalltalk is just so foreign - it comes at you with a new syntax,
 philosophy, user-interface and terminology all at once.  It's a tough first
 few months for novices, even dedicated ones.  ACTOR can be used in a
 procedural manner without having to ponder all of the deep philosophical
 implications of what you're doing until later.  Overall, ACTOR is leaner,
 simpler, and tighter than Smalltalk.  I believe that each new thing added to
 a language must be examined harshly for its effects on complexity,
 learnability and what power it contributes.  In terms of garbage collection,
 we employ an incremental, scavenging collector based upon Baker's paper from
 MIT.  The idea is that you constantly copy the objects that are alive from
 one place to another, naturally compacting and collecting garbage at the same
 time.  It lends itself well to incremental collection and real-time use, and
 is now  finding its way into many Smalltalk and Lisp systems.

(Shepard) For those of you who want to read more, on this, and Chuck would you
 agree,an article from ACM Communications called "A Real-Time Garbage
 Collector Based on the Lifetimes of Objects" by Lieberman and Hewitt might be
 informative. June, 1983. I am sure we have questions from Marc Rettig (finger
 pointing)!

(Rettig) Chuck, could you describe the library of classes that comes with
 ACTOR?

(Duff) Part of that was garbled - I assume you mean library of classes and
 including about 20 collection classes.  We also support the Windows graphics
 systems via objects that lead "dual lives".  An interesting group of classes
 is the Parser, which provides a state-machine that understands YACC output,
 enabling you to build your own custom grammars very easily.

(Anderson) Yes, I was wondering if you had done any "Human Factors" studies on
 the ACTOR user interface and on the decision to build on Windows?

(Duff) Nothing scientific, just gut feel.  The Windows decision involved a
 number of issues.  A Windowing interface was considered essential for the
 sophisticated tools we wanted to provide, such as Browsers, Inspectors, etc.
 In my opinion,  the Windows war was won last winter, when Windows really
 picked up some momentum.  Microsoft has a unique position in the industry
 in terms of DOS, and that link will become increasingly important.  Right now
 we're seeing a lot of activity among OEMs in doing new device drivers.  For
 instance, I work on a 1200 by 1000 Viking monitor that looks like a Sun
 workstation, and I didn't  have to write a line of code to support it!!!
 That is a profound advantage for the developer, and also a tremendous
 advantage over languages that own the system, such as Smalltalk.


(Shepard) John, a follow-up?

(Anderson) I am only slightly familiar with Windows and ACTOR.  I was
 wondering about how an end user application might feel in ACTOR.


(Duff) Windows uses tiled windows, which is somewhat different.  We tend to
 use popups (Mac-like) for a lot of things, because they are more familiar and
 flexible.  You can create just about anything you want, in fact you could do
 an application that was very Macintosh-like if you wish.  We don't prescribe
 how the environment is used.

(Rettig) Chuck, Smalltalk/V will let you have more objects than will fit in
 memory by performing "object swapping".  Does ACTOR have such a thing?

(Duff) You have to understand that Smalltalk/V is at a very different place in
 its life cycle than ACTOR, being a mature product.  We are building a virtual
 object mechanism for a future release, but have some concerns about its value
 in current environments.  For instance, as soon as memory stops being a
 limitation, the number of object pointers is the next wall.  We see the real
 solution as being protected mode, which demands a very different architecture
 overall.  We are actively developing a system that will be more like mini
 -based OOLs, and use the full resources of protected mode.

(Rettig) A follow up, Susan?


(Shepard) Go ahead.

(Rettig) I understand your points, Chuck, and they are well taken.  But I want
 to develop an OO database that will have say, 20 meg of objects stored very
 *securely*. That is, I want them to be there even after I recover from a
 pulled plug.  Will your virtual objects be suited for this kind of thing?

(Duff) I worked on Tandem systems for a number of years.  Even with redundant
 hardware, that goal was not totally achievable.  Realistically, I think you
 will be hard-pressed to do it on PCs.  Also, how many objects do you envision
 occupying your 20 meg?

(Rettig Oh, on the order of tens of thousands.

(Duff) Non-protected mode OOLs provide between 16K and 32K objects. The
 virtual object facility that we are planning as an interim step will probably
 not be as secure as you require.  I think that a true OO database facility
 demands more than object-swapping.  You need persistent objects that could
 occupy a much wider pointer space on disk than in memory. That is a future
 goal of ours, but a separate one.

(Rettig) Thank you.  Sounds great.

(Shepard) Go ahead, Jeff.

(Gordon) Ok... Nice to meet you, Chuck..... Realizing they are, of course, for
 different machines I'd like to hear Chuck's assessment, similar to what he
 provided for ACTOR at the top of the CO, on NEON!, and also, now that ACTOR
 exists, would like to hear what Chuck _now_ thinks of NEON! from a "father's"
 eye view.

(Duff) Teenagers these days, they don't listen... Neon was designed with a
 different goal in mind, and as such, I feel it was successful on some counts
 and not on others.  Neon came about because I had to move Typing Tutor III,
 which we had written in Forth on the PC, to the Mac.  The only alternative at
 the time was Lisa Pascal, which was this medieval, undocumented, very slow
 system that seemed like some sort of punishment for something I hadn't done.
 So I initially set out to bring up a Forth system on the Mac. I had some
 ideas about generic operators that grew out of Forth -- multiple-codefield
 words, and that proved to be a weak version of true polymorphism as seen in
 Smalltalk.  Thus, Norm Iverson and I ended up with Neon, which soon became a
 lot more fun than porting Typing Tutor for the Nth time. Because it grew so
 directly out of Forth, we kept the open stack and RPN notation, which I now
 consider its weakest points. As an OOL, it's a hybrid, which has its pluses
 and minuses. You can still get into trouble, just in a lot more interesting
 and bizarre ways.  I like the relative sparseness and terse quality of the
 language, which it also inherits from Forth.   Actually, on BIX we had a
 panel discussion of OOL people and coded an example in each language.
 Surprisingly, Neon required the most code, and ACTOR the least (source).

(Gordon) Follow-up?

(Shepard) Yes

(Gordon) Ok.... Any future plans (that you know of) for changing/enhancing
 Neon; and any Mac-related projects on your drawing board?

(Gordon) In terms of Neon, I left Kriya because I hadn't been paid in 14
 weeks, and that has sort of set the tone.  My impression is that it is
 getting very weak support and almost no marketing doesn't bode well for its
 future.  We have definite plans for a Mac version of ACTOR, and one of our
 goals is completely transparent source between Windows and the Mac, which I
 think will make a lot of people happy.

(Gordon) Definitely....usage is rather simple, although today is slow. You
 might consider (ahem) a substantial trade-in offer for folks who'd like to
 trade Neon for ACTOR.  Thanks, Chuck.

(Duff) Good idea.

(Shepard) Marc.

(Rettig) Not sure how to phrase this.  I'm wondering about the similarities
 between the development environments of Smalltalk and ACTOR.  Will I see the
 familiar browers and inspectors?  Will the debugging feel the same?  I know
 you made the syntax more Pascal-like. Does this mean a Pascal or C programmer
 can learn ACTOR faster than SMalltalk?

(Duff) Unqualified yes on the last question.  I had a student (who is
 currently writing much of the manual)  pick up ACTOR in a couple of weeks,
 with only Turbo Pascal experience and no OOLs.  The environment is very much
 like ST, only the windowing is much cleaner and faster.  For instance, our
 edit windows keep up with your typing.  There is a browser that allows you to
 examine and edit classes and their methods, an Inspector that provides a
 visual interface to objects' private data, a workspace, and so on. When an
 error occurs, a dialog presents the stack history that led up to the error.
 Clicking on one of the stack frames converts it into a Context object, and
 starts an Inspector so you can examine the message send in detail, including
 the receiver, arguments, locals, etc.  It's a lot of fun, because its fast,
 powerful, and easy to use.

(Rettig)  Thanks.  Sounds fun, alright.

(Rettig) I'll repeat:  Chuck, is ACTOR shipping yet?  If not when?  Have you
 taken lots of orders?

(Duff) I'm putting the finishing touches on it right now (or would be if I
 wasn't talking with you all) and we'll be shipping in mid-December.  We have
 had a tremendous amount of interest surprisingly much of it has come from
 large corporations.  It seems that OOP and Windows are two separate but
 important currents in personal computing today, and we can bring them
 together.  A few years ago, it seemed that OOP was about as popular in big
 corporations as Scientology, but right now there is really a ground swell of
 interest.

(Gordon)  If I remember what I read price tag is $495, and a HD is considered
 a necessity.  True?

(Duff) Don't forget $99 for academic users, and anybody who uses Windows
 should have a HD.

(Gordon) And of course a 93% discount for those here today?


(Duff) We can talk about it.

(Rettig) You mentioned earlier that ACTOR is "presently" single-inheritance.
 Can I read into that plans for multiple inheritance in the future?

(Duff) I don't think I know anybody in the OOP community who thinks they know
 the best way to do multiple inheritance.  Flavors is one of the most complex
 things I've ever seen, and I hope no one is controlling ICBMs with Flavors
 code.  I am constantly looking  at M-I alternatives, but as I said before,
 the value it introduces has to be worth the added complexity.  Right now, you
 can build composite objects that own several other classes as instance
 variables, and kind of get around it.  That is well-understood, but not
 terribly pretty.  That's where I'm at.  I'm always open to suggestions!

(Rettig) Thanks.  All good points.

(Anderson) I'm sitting here trying to bone up on the article in BYTE.  I'm
 pretty well snowed.  I have had experience with flavors on the lisp machine,
 but I can't say whether I'd trust them in an ICBM situation either.

(Duff) Susan, perhaps in the future, when Actor is released, we can  use the
 Forum as a place to post AI-related code, ideas, etc?

(Shepard) I would be glad to!

(Anderson) I was wondering what plans you had to move ACTOR to a main-frame.
 At TI, we are constanly being asked.

(Duff) The real question is, does anyone have plans to move a mainframe to me?
 Not right now, but it would be possible if we had access to one.  We have
 been approached about doing a UNIX port, and that seems very likely.

(Shepard) Chuck, have you seen SCOOPS?

(Duff) No, I haven't.  Interested, tho.

(Shepard) Chuck - there is a SCOOPS.ARC in DL 2.  John, any comments on that?

(Anderson) I didn't get the end of your question.

(Shepard) I was just directing Chuck to the SCOOPS.ARC.
(Anderson) I'm not a compiler expert.  However, we did find that we could do
 without using the SCOOPS package, and still program in an object like
 fashion.  I personally am very interested in objects, but I have been led to
 believe that the penalty in speed and memory is too high. I appologize for
 taking so long to get my thoughts together.

(Shepard) No problem, John - that's why we conference.

(Shepard) Marc

(Rettig) I would be interested in Chuck's response to John's last remark about
 the speed and memory penalties of using an OO language.

(Duff) Both Neon and ACTOR have satisfied me that it is possible to do
 extremely practical things in OOLs without the penalties that we've grown
 used to with Smalltalk and Lisp. ACTOR is the first non-hybrid OOL to
 actually perform acceptably in my rather biased opinion.

(Shepard) John.

(Anderson) I was wondering if you had done any benchmarks.

(Duff) Lots of informal ones.  We're still optimizing the compiler, so nothing
 is final.  We run the fib Smalltalk benchmark in under 30 seconds on an 8 mhz
 AT, if that means anything.

(Shepard) FIB(N) = what (N)?

(Duff) I think its fib(12) 1000 times.  It's not a good benchmark in a lot of
 ways, since it doesn't test the garbage collector at all, etc.

(Shepard) Mark A. told me something about a game you had "compared" with
 TurboPROLOG.

(Duff) We coded an N-Queens problem in Actor.  It runs in around 6 secs in
 Actor, vs. 3.5 minutes in TurboProlog.  Again, not terribly fair, because its
 hand-coded backtracking vs. totally general backtracking, but I guess
 benchmarks are like that.

(Shepard) Instead of MIPS we have MIPP - Meaningless Inventory of Product
 Performance! <grin>

(Shepard) Did you have a question, Marc?

(Rettig) One last question, and my list is empty.  Chuck, you mentioned BIX.
 I understand a lot of interesting things in OOP go on over there.  Yes?
 Also, where is the best place to send you mail?  Do you have a Compuserve ID
 other than the one you are using now?

(Duff) Yeah, the Smalltalk conference on BIX is fairly active level.

(Shepard) We've taken a lot of Chuck's time.

(Rettig) A thousand thanks, Chuck.

(Gordon) <considerate applause from Atlanta>

(Anderson) Austin says thanks also.

                                  THE END